home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
NetNews Offline 2
/
NetNews Offline Volume 2.iso
/
news
/
comp
/
std
/
c
/
602
< prev
next >
Wrap
Text File
|
1996-08-06
|
2KB
|
45 lines
Newsgroups: comp.std.c
Path: blackbush.xlink.net!slsv6bt!news
From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
Subject: Re: BoundsChecker and fgets fmalloc problems
In-Reply-To: bri@primenet.com's message of 18 Mar 1996 12:48:01 -0700
Message-ID: <KANZE.96Mar19110432@slsvhrt.lts.sel.alcatel.de>
Sender: news@lts.sel.alcatel.de
Organization: GABI Software, Sarl.
References: <4ikelh$gji@nnrp1.news.primenet.com>
Date: 19 Mar 1996 10:04:31 GMT
In article <4ikelh$gji@nnrp1.news.primenet.com> bri@primenet.com (Brian
Gregory) writes:
|> I am using Bounds Checker v2.5, and am having a problem finding a
|> memory leak it is reporting...
|> Example:
|> fgets( szBuf, 799, fpIn );
|> szBuf is an 800 character buffer (pre-sized array)
|> fpIn IS a valid pointer
|> no memory is corrupt before the fgets line
|> The application is a windows app, written in straight C with a large
|> memory model.
|> The problem is Boundschecker consistently reports memory leaks for the
|> larger buffer size mallocs contained WITHIN the fgets function...
Is fpIn ever closed? (If it is stdin, it normally won't be.) Most
implementations of stdio will allocate a large buffer (for buffering
purposes) on the first IO to the file, and free it when the file is
closed. If the file is never closed...
All of the memory checkers I'm familiar with (Purify and my own) have
the possibility to state that certain `leaks' are normal, and shouldn't
be mentioned.
--
James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
-- A la recherche d'une activitΘ dans une region francophone